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(54) Scheduling videos in a video-on-demand system 



(57) A system and method for scheduling the 
number of channels in video-on-demand servers so as 
to deal with time varying load . The scheduling process 
is hierarchical. A higher level scheduler (210) controls 



the rate o f channel consumption based on anticipated 
load, and a lower level scheduler (220) selects the wait- 
ing client requests to be served when a channel is allo- 
cated by the higher level scheduler (210). 
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Description 

The present invention relates to a video on demand 
system of the type wherein multiple clients are serviced 
by video streams delivered from a video server. The in- 
vention also relates to a method of scheduling videos in 
such a video-on-demand system. 

Video-on-demand (VOD) servers commonly in- 
clude a group of centralised sen/ers that store a large 
number of videos on disks and play these videos to 
widely distributed clients. Unlike conventional applica- 
tions, VOD applications have hard real-time response 
requirements to ensure a continuous delivery of data to 
the clients. Hence video senders need to ensure that suf- 
ficient resources are available both at the server and in 
the network to guarantee uninterrupted delivery of a vid- 
eo stream. These resources are referred to as a chan- 
nel. 

In general, clients request videos independently of 
each other. A new stream may be started to satisfy each 
request if enough resources are available. However, ' 
multiple requests for the same video can be served by 
a single disk I/O stream by sending the same data pages 
to multiple clients. This is referred to as batching. The 
batching factor is the average number of requests 
batched together. 

In VOD systems, the load may be transient in na- 
ture. For example, the rate of requests may start going 
up at 6 PM, peak at 8 PM and again subside after 10 
PM. During periods of high load, it is likely that there will 
be multiple requests for the popular movies within a 
short period of time that can be batched together. Batch- 
ing is thus mostly useful during periods of high load. Dur- 
ing periods of low load, it may be preferable to allocate 
an Individual stream for each movie or to have a lower 
batching factor. Due to the long viewing times of videos, 
it Is possible that channels allocated during periods of 
low load are not available during the peak period. Thus 
sufficient channels may not be available during the peak 
period to service the load. 

According to a first aspect of the present invention, 
there is provided a method of scheduling videos in a vid- 
eo-on-demand system, comprising the steps of: 

receiving a plurality of requests from users of the 
system, for playing of the videos; 

determining a time a t which a next playing of a video 
by the video-on-demand system will occur based 
on present availability of system resources and an- 
ticipated load on the system; 

selecting a particular video to play based at least in 
part on attributes of the requests which have not yet 
been serviced; and, 

after the selecting and when the time for the next 
playing arrives, playing the particular video to serv- 



ice at least some of the requests. 

Preferably, the anticipated load on the system is de- 
termined by a method as claimed in claim 1 . wherein the 
5 anticipated load on the system is determined as a func- 
tion of at least anticipated new requests and anticipated 
completions of requests currently being served. 

According to a second aspect of the present inven- 
tion, there is provided a method of scheduling videos in 
10 a video-on-demand system, comprising the steps of: 

receiving requests for playing of videos from users 
of the system; 

IS tracking the requests in a queue structure; 

requesting use of system resources for playout of 
at least one of the videos identified by the requests 
in the queue; 

20 

responsive to the requesting, comparing an 
elapsed time between a last playing of a video and 
the requesting of the use of system resources to a 
threshold value; 

25 

when the comparing indicates that the elapsed time 
does not exceed the threshob value, postponing al- 
location of system resources to the request; 

30 when the comparing Indicates that the elapsed time 
exceeds the threshold value, allocating system re- ' 
sources to the request and playing out the at least 
one of the videos. 

35 According to a third aspect of the present invention 
there is provided a method of scheduling physical re- 
sources in an on-demand customer sen^ice system of a 
type wherein a single resource can be used to satisfy 
multiple requests and wherein allocated resources can 

40 not be reclaimed until service completion, comprising 
the steps of: 

receiving, from a user of the system, requests for 
allocation of the physical resources to the customer 
^ requests; 

tracking the requests for allocation in a queue struc- 
ture; 

so I determining a time at which at least one of the phys- 
ical resources will be next allocated based on both 
present availability of system resources and antici- 
pated load on the system; 

ss selecting a particular resource to allocate based on 
attributes of the requests in the queue. 

According to a fourth aspect of the present invention 
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there is provided a video on demand system, comprising 
the steps of: 

a network interface coupled to receiving requests 
for playing of videos from users of the video-on-de- 
mand system; 

a memory having a queue structure formed therein, 
the queue structure Including information indicative 
of the requests; 

(a first schedule r instantiated in the memory, the first 
scheduling including: (i) means for selecting at least 
one of the videos for playout based on attributes of 
the requests indicated In the queue structure, and; 
(li) means for requesting use of system resources 
for playout of at least one of the videos selected by 
the means for selecting; 

a second schedule r Instantiated in the memory the 
second scheduling including: (i) means responsive 
to the requesting, for comparing an elapsed time 
between a last playing of a video and the requesting 
of the use of system resources to a threshold value, 
and; (11) means for allocating system resources to 
the request made by the means for requesting, 
when the comparing indicates that the elapsed time 
exceeds the threshold value; and, 

a video player coupled to the second scheduler for 
playing the at least one of the videos. 

Further, the present invention provides a computer 
readable memory that can be used to direct a computer 
to schedule videos in accordance with a method of the 
present invention when used by the computer. . 

The present Invention provides a system, method 
and computer program product for scheduling the 
number of channels In video-on-demand servers so as 
to deal with a time varying load. Requests (from users) 
are received for playing of videos. A time for a next play- 
ing of a video by the video-on-demand system Is deter- 
mined based on present availability of system resources 
and anticipated load on the system. Also, particular vid- 
eo to play is selected from those requested, based at 
least In part on attributes of the requests which have not 
yet been serviced. After the video is selected and when 
the time for the next playing arrives, the particular video 
is played to service at least some of the requests. 

In a preferred embodiment, the scheduling process 
is hierarchical. A higher level scheduler controls the rate 
of channel consumption based on anticipated load, and 
a lower level scheduler selects the waiting client re- 
quests to be sen/ed when a channel is allocated by the 
higher level scheduler. Thus, system resources are con- 
sented at the time of low load by rejecting client requests 
or delaying playback of videos to increase the batching 
factor in anticipation of higher load in the near future. 



The invention will now be described, by way of ex- 
ample, with reference to the accompanying drawings, 
in which: 

5 Fig. 1 is a block diagram of a video-on-demand sys- 
tem according to an embodiment of the present in- 
vention; 

Fig. 2 is a block diagram of the scheduler of Fig. 1 ; 

10 

Fig. 3 shows the handling of a new request for a 
stream made by a client; 

Fig. 4 shows the handling of a request for channel 
IS made by the lower level scheduler to the higher lev- 
el scheduler. 

Fig. 5 shows the handling of the event of a channel 
allocated to the lower level scheduler; and. 

20 

Fig. 6 shows the processing of the event of a chan- 
nel freed by the video playback system. 

Fig. 1 is a block diagram of a video-on-demand sys- 
2S tem according to an embodiment of the present inven- 
tion. The video-on-demand system includes a video 
sender 130, wherein videos (e.g. movies) are stored in 
storage devices such as a disk array 132. The video 
server 130 Is coupled to a communication network 120 
30 by way of conventional network interface 118. Clients 
1 1 0 make requests to the video server 1 30 via the com- 
munication network 120. Clients can submit start, stop, 
pause and resume requests by way of client stations 
122. In order to facilitate batching, VCR control and oth- 
3S er functions, the requested videos (or segments of the 
requested videos) are loaded into a memory buffer 1 34 
from the disks 1 32 and then served to the clients via the 
buffer 134. 

The video sender 130 includes a processor (cpu) 

40 112 which performs under control of the various pro- 
grams residing in a main memory 114. These programs 
Include a scheduler 140 that reserves a channel (i.e., 
resources) before the start of video playback, and a vid- 
eo player 150 that can start, stop, pause and resume of 

45 video playback upon client request after the scheduler 
makes a channel available. Those of skill in the art will 
recognise that a number of conventional software proc- 
esses 116, not described in detail here, are also involved 
in the control and support of the video server functions. 

50 The video sen/er 100 can be embodied using any 
processor of sufficient performance for the number of 
video streams to be supported. For example, a small 
capacity video sen/er could be embodied using a RISC 
System/6000 TM system while a larger capacity sen/er 

55 could be embodied using an ES/9000 TM system (both 
available form International Business Machines Corpo- 
ration of Armonk, New York). This disks 1 32 can be em- 
bodied as any conventional disk subsystem or disk ar- 
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ray. The communication network 120 can be, for exam- 
ple, a fibre optic network or a conventional bi-directional 
cable network. The client stations 1 22 can be embodied, 
for example, as a set-top box. 

Fig. 2 shows the components of the scheduler 140 
of Fig. 1 . and their Interactions with the video player 1 50 
of Fig. 1. The scheduler includes two components, a 
High Level Scheduler (HLS) 210 and a Low Level 
Scheduler (LLS) 220. The HLS and the LLS are embod- 
ied as program code and associated data structures in- 
stantiated in the memory of the server. Signalling be- 
tween the HLS and LLS and between the scheduler and 
other modules is accomplished by setting and resetting 
flags or status bits indicative of various conditions and 
requests. 

The HLS 210 maintains a flag 240 called 
CHAN_REQ_Fl_AG and a counter for the number of free 
channels, FREE_CHAN_CNT 245. Client requests for 
the start of a new video 260 are queued in the 
REQ.QUE 250 of the LLS 220. The LLS 220 sends "Re- 
quest channel" signal 265 to the HLS to schedule wait- 
ing client requests for start of a new video. The HLS 21 0 
sends signal "Channel available" back to LLS 220 once 
it allocates a channel. The LLS 220 then selects a video 
to play and batches all waiting client requests for that 
video. It then sends the signal "Use channel to play vkd- 
eo" to the Video Player 230. 

The selection of which video to play depends on 
various attribute s of the client requests waiting in the 
queue, p olicy objectives as well as the supported sen^- 
Ice class. Client request attributes Include, for example, 
the amount of time eac h client has waited, their reneging 
time threshold (how long each client is expected to be 
willing to wait), and the service time re quirement for the 
video (i.e. how long the system resources are expected 
to be needed for playing of the video). The policy objec- 
tive can be, for example, to minimise overall reneging, 
fairness or p noritisin q one class of requests over others. 
For example one requester might received deluxe or 
preferred class service tor a higher fee and thus be 
served on a priority basis. 

A particular embodiment of the ULSjQiipy is FCFS 
(first come first sen/e). In accordance with FCFS, the 
request in the front of the queue is served first and all 
other clients waiting for the same video are batched to- 
gether when the request is sen/iced. Thus, FCFS sc hed- 
ules videos based on the attributes of (1 ) position in the 
queue and (2) which video has been requested. Special 
treatment can be given to "hot" (popular) videos. In ac- 
cordance with this policy (sometimes referred to as 
FCFS-n), hot videos are served from special queue pro- 
vided for that purpose. 

Like the scheduler 140, the Video Player 230 is em- 
bodied as program code and data structures instantiat- 
ed in the memory of the video server. The Video player 
230 pauses, resumes and stops playback of videos up- 
on corresponding client requests. After the playback of 
a video is stopped the Video Player 230 sends the signal 



"Channel free" 280 to the HLS 210. 

The handling of a new client request for start of a 
video is shown in Fig. 3. A client request is received by 
the LLS in step 310. In step 320 the LLS 220 checks if 
5 REQ_QUEUE is empty. If the queue Is not empty then 
the new request is added to the REQ_QUEUE in step 
330. Otherwise, the request is added to the 
REQ_QUEUE in step 340 and the LLS sends "Request 
channel" to the HLS in step 350. 
10 The handling of "Request channel" by the HLS is 
shown in Fig. 4. In step 420 the HLS 210 checks to see 
if the time duration since the last time a channel was 
allocated to the LLS is greater than some prespecified 
threshold. TJh. In cases where little or no Information 
IS concerning the future load is known , TJh is set to a fixed 
value. Preferably, this fixed value Is the ratio of average 
holding time of a channel by the clients to the total 
number of channels In the VOD system. However, if the 
future load can be anticipated with more accuracy, then 
T th can be made a function of the time of the day. If the 
time duration since the last time a channel was allocated 
to the LLS is not greater than TJh then the HLS waits 
for the remaining time in step 430. When the time dura- 
tion since the last time a channel was allocated to the 
LLS becomes greater than TJh, in step 440 the HLS 
checks to see, if the FREE_CHAN_CNT is greater than 
zero. If not, in step 470 the HLS sets the 
CHAN_REQ_FLAG. Othenwise, in step 450 the HLS 
decrements the FREE_CHAN_CNT, and sends the sig- 
nal 'Channel available" to LLS in step 460. 

The handling of 'Channel available" by the LLS is 
shown in Fig. 5. In step 520 the LLS selects a video to 
play on the available channel depending on the waiting 
client requests, and batches all clients waiting for this 
video playback to start. In step 530 the LLS sends the 
signal "Use channel to play video' to the Video Player 
230. Then, in step 540 the LLS checks to see if the 
REQ_QUEUE is empty after the batched clients are tak- 
en out of the queue. If not, in step 550 the LLS sends a 
signal "Request channel" to the HLS. 

Finally, the handling of "Channel free' by the HLS 
Is shown in Fig. 6. In step 620 the HLS increments the 
FREE_CHAN_CNT to reflect one more available chan- 
nel. The HLS then checks to see, in step 630, if the flag 
CHAN_REQ_FLAG is set. If the flag is on, in step 640 
the HLS resets this flag, and in step 650 the HLS proc- 
esses the handling of signal "Request channel'. 

It should be understood that the present system and 
method can be employed to schedule events and phys- 
ical resources other than videos. For example, the 
present system and method can be used to schedule 
physical resources in an on-demand customer sen/ice 
system of a type wherein a single resource can be used 
to satisfy multiple requests and wherein allocated re- 
sources can not be reclaimed until sen^ice completion 
(e.g. shuttle sen^ice). . . 
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Claims 

1. A methcxi of scheduling videos in a video-on-de- 
mand system, comprising the steps of: 

receiving a plurality of requests from users of 
the system, for playing of the videos; 

determining a time at which a next playing of a 
video by the video-on-dennand system will oc- 
cur based on present availability of system re- 
sources and anticipated load on the system; 

selecting a particular video to play based at 
least In part on attributes of the requests which 
have not yet been serviced; and, 

after the selecting and when the time for the 
next playing arrives, playing the particular vid- 
eo to service at least some of the requests. 

2. A method as claimed Claim 1 , wherein the antici- 
pated load on the system is determined as a func- 

. tion of at least anticipated new requests and antic- 
ipated completions of requests currently being 
served. 

3. A method as claimed in Claim 1 or 2, wherein the 
attributes are selected from a group including: a 
number of requests for a common video, waiting 
time for each of the requests, expected reneging 
threshold for the users and class of service. 

4. A method as claimed in Claim 1 , 2 or 3, wherein the 
determining a time at which a next playing of a video 
by the video-on-demand system will occur includes 
the step of determining whether a time period be- 
tween a desired scheduling of a video and a previ- 
ous scheduling of a video has exceeded a prede- 
termined threshold; and, when the time period has 
not exceeded the threshold, postponing the playing 
until the threshold has been exceeded. 



sources to a threshold value; 

when the comparing indicates that the elapsed 
time does not exceed the threshold value, post- 
s poning allocation of system resources to the re- 

quest; 

when the comparing indicates that the elapsed 
time exceeds the threshold value, allocating 
10 system resources to the request and playing 

out the at least one of the videos. 

6. A method as claimed in Claim 4 or 5, wherein the 
threshold is a fixed number. 

IS 

7. A method as claimed in Claim 4 or 5, wherein the 
threshold is determined based on a rate at which 
the load on the system is changing. 

20 8. A computer readable memory that can be used to 
direct a computer to schedule videos in accordance 
with a method as claimed in any one of the preced- 
ing Claims. 

25 9. A method of scheduling physical resources in an 
on-demand customer service system of a type 
wherein a single resource can be used to satisfy 
multiple requests and wherein allocated resources 
can not be reclaimed until service completion, com- 

jo prising the steps of: _ 

receiving, from a user of the system, requests 
for allocation of the physical resources to the 
customer requests; 

35 

tracking the requests for allocation in a queue 
structure; 

determining a time at which at least one of the 
40 physical resources will be next allocated based 

on both present availability of system resources 
and anticipated load on the system; 




35 



5. A method of scheduling videos in a video-on-de- 
mand system, comprising the steps of: ^ 

receiving requests for playing of videos from 
users of the system; 

tracking the requests in a queue structure; 50 

requesting use of system resources for playout 
of at least one of the videos identified by the 
requests in the queue; 

55 

responsive to the requesting, comparing an 
elapsed time between a last playing of a video 
and the requesting of the use of system re- 



selecting a particular resource to allocate 
based on attributes of the requests in the 
queue. 

10. A video on demand system, comprising: 

a network interface (118) coupled to receiving 
requests for playing of videos from users (110) 
of the video-on-demand system; 

a memory (114) having a queue structure (250) 
formed therein, the queue structure (250) in- 
cluding information indicative of the requests; 

a first scheduler (220) instantiated in the mem- 
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ory (114), the first scheduler (220) including: (i) 
means for selecting at least one of the videos 
for playout based on attributes of the requests 
Indicated In the queue structure (250), and; (it) 
means for requesting use of system resources s 
for playout of at least one of the videos selected 
by the means for selecting; 

a second scheduler (210) instantiated in the 
memory (114), the second scheduler (210) in- io 
eluding: (i) means responsive to the requesting, 
for comparing an elapsed time between a last 
playing of a video and the requesting of the use 
of system resources to a threshold value, and; 
(ii) means for allocating system resources to is 
the request made by the means for requesting, 
when the comparing indicates that the elapsed 
time exceeds the threshold value; and, 

a video player (230) coupled to the second 20 
scheduler (210) for playing the at least one of 
the videos. 
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